In most data communication systems, it is required to assure the complete and integral transmission of information frames between two systems. In the present case, both systems operate according to a certain protocol that uses timers. Therefore, each time a frame is sent, a timer is used to control the reception of an acknowledgment and if necessary, to start a confirmation mechanism in order to retransmit the information frame that is not received.
The X25 LAPB (Link Access Procedure-Balanced) operates according to the above described communication protocol. The X25 LAPB protocol enables transmission of Information Frames (called Iframes) and assures the integrity of the transmission by retransmitting Iframes that are not received. Each Iframe is controlled by a timer, called Retry Timer or T1 Timer for the X25 LAPB. If the transmitted Iframes are not acknowledged when the T1 Timer expires, then the LAPB starts the confirmation mechanism in order to re-transmit.
FIG. 1 shows the different elements which are required to transmit a frame from a first LAPB (10) to a remote LAPB which is connected through a physical line (51). The LAPB component (10) enqueues a pointer (11) of a buffer on the top of a Transmit Queue (30). The buffer which contains the Iframe to be transmitted is stored in a RAM memory (20). The Transmit Queue (30) is a chained list of pointers associated to buffers stored in RAM memory (20). The chained list is of the type FIFO (First In First Out).
A Transmit Scheduler (40) dequeues a first available pointer (31) from the Transmit Queue (30) and it reads the associated buffer (21) in RAM memory (20). Then, it provides the Iframe (41) contained in the buffer to a hardware circuit (50) which transmits the frame on the Physical Line(51) to the remote LAPB.
Once the Iframe is transmitted, the Transmit Scheduler(40) dequeues the next pointer (31) of the Transmit Queue(30). But the Iframe is released from the RAM memory (20) only when the previous frame has been acknowledged by the remote LAPB.
One of the principal problem found by the customer using X25 LAPB is the random loss of the X25 link due to a wrong appreciation of the T1 Timer value. Indeed, this value has to be defined according to the transmission speed which is inherent to type of the transmission links, and the workload of the link, the latter being tough to evaluate.
In the background art, the T1 Timer is defined once during the network configuration according to the speed of the physical line (51). T1 Timer value is always statically defined, it is never changed unless another configuration is performed. Each time, the value of T1 causes problems, it is adjusted manually in order to meet the requirement of workload of the link, which results in a waste of time due to the interruption of the link.
FIG. 2 shows the flow defined in the X25 LAPB as used in the prior art when the Iframe is not received. As is already explained above, the LAPB component (10) stores the Iframe in a buffer memory, starts the T1 timer and enqueues the Iframe in the Transmit queue. Afterwards, the Iframe is dequeued from the Transmit Queue by the Transmit Scheduler and sent to the remote LAPB by the hardware circuit (50). But the Iframe cannot be received by the remote LAPB because of an error in its integrity detected by the hardware circuit (50).
The T1 Timer expires. As no acknowledgment has been sent from the remote LAPB; the T1 timer is restarted so as to force the remote LAPB to give information of the last received Iframe by sending a Received Ready Command Polled (RRp) frame.
The remote LAPB responds with a Received Ready Response Final (RRf) frame containing the sequence Number of the Iframe that it is waiting for. The LAPB (10) restarts the T1 timer and resends the Iframe if it has not been received yet. This Iframe is in this case polled to force the remote LAPB to acknowledge its reception. The remote LAPB receives the Iframe polled and acknowledges it with a RRf frame. When the LAPB (10) receives the RRf frame, it stops the T1 timer and releases the Iframe from the memory.
FIG. 3 shows the flow in case an Iframe is kept for too long in the Transmit Queue, because of a traffic overload. Chronologically, the LAPB (10) stores the If Iframe in memory (20), starts the T1 timer and enqueues the Iframe in the Transmit queue. When an Iframe which is kept during a long time in the Transmit Queue is dequeued by the Transmit Scheduler to be sent to the remote LAPB by the hardware circuit, by the time the LAPB (10) receives the remote LAPB acknowledgement of the Iframe reception, the T1 timer has expired. Since T1 Timer has expired, the LAPB (10) starts again the T1 timer and sends a Received Ready Command Polled frame (RRp) to force the remote LAPB to give information of the last received Iframe. But, when the remote LAPB has received the Iframe it has already sent a first Received Ready Response Final frame (RRf) before the LAPB has started T1 Timer. Therefore, the LAPB (10) receives the first de-synchronized RRf, then it stops the T1 timer and releases the Iframe from the memory.
During that time, the remote LAPB receives the RRp and responds again with a Received Ready Response Final frame (RRf). When the LAPB (10) receives this second RRf and processes it as an unexpected Final Bit and it breaks the connection.
Other cases of de-synchronization due to the same reason can be found especially in the case of a Dynamic Windowing implementation. The Dynamic Windowing is rarely implemented with the LAPB protocol but is frequent with the IEEE 802.2 protocol for environments including Token Ring with bridges or Frame Relay. For more information about X25 LAPB refer to the documentation relating to the recommendations ITU.sub.-- T normalization X.25 revised 1993.